home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group99a.txt / 000100_icon-group-sender _Mon Apr 12 08:12:54 1999.msg < prev    next >
Internet Message Format  |  2000-09-20  |  5KB
  1. Return-Path: <icon-group-sender>
  2. Received: (from root@localhost)
  3.     by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA07932
  4.     for icon-group-addresses; Mon, 12 Apr 1999 08:11:23 -0700 (MST)
  5. Message-Id: <199904121511.IAA07932@baskerville.CS.Arizona.EDU>
  6. From: Todd Proebsting <toddpro@microsoft.com>
  7. To: "'Mark Evans'" <evans@gte.net>,
  8.         Icon List
  9.      <icon-group@optima.CS.Arizona.EDU>
  10. Subject: RE: Ccon and Icon-based Compilers
  11. Date: Mon, 5 Apr 1999 09:23:44 -0700 
  12. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  13. Status: RO
  14.  
  15. Jcon's translator is written in Icon.  It would be very easy to adapt it to
  16. emit C++ (or assembly for your favorite machine).  In fact, the translator
  17. was structured to be easy to retarget.  (I'm toying with the idea of
  18. retargetting Jcon to emit Postscript---with only a limited run-time
  19. system---just for kicks....)
  20.  
  21. The problem is not translating Icon, however, but providing the run-time
  22. support for all of Icon's built-in types and functions.  This can be done
  23. easily in C++, too, with enough time.  With the exception of the graphics
  24. stuff, most of Jcon should translate pretty cleanly into C++.
  25.  
  26. Two issues that any Icon implementation must face are how to handle
  27. co-expressions, and how to handle garbage collection.  Co-expressions are
  28. easy if you have a threads package.  Garbage collection is a royal pain.
  29. Jcon relied on Java's garbage collection, so GC in Jcon was free.  Unless
  30. you use a conservative collector in a C++ implementation, I think GC would
  31. be complete mess: a source of lots of complications, lots of performance
  32. problems, and lots of hard-to-track bugs.
  33.  
  34. I should comment, however, on emitting machine code.  It's not going to help
  35. performance much at all.  The vast majority of the time in an Icon program
  36. is spent in the run-time system, not in compiled code.  In Jcon, its around
  37. 10% in compiled code, if I recall correctly.  (The old Icon compiler, iconc,
  38. had significant performance gains not because it compiled to C rather than
  39. being interpreted, but because it did type inferencing to avoid having to do
  40. lots of type conversions and type tests.  This is an orthogonal issue to
  41. what target or implementation languages are used.)
  42.  
  43. I'd be surprised if any implementation of Icon is going to be significantly
  44. faster than the current interpreter unless the new implementation does
  45. type-specific optimizations.
  46.  
  47. Todd
  48.  
  49. -----Original Message-----
  50. From: Mark Evans [mailto:evans@gte.net]
  51. Sent: Saturday, April 03, 1999 8:35 AM
  52. To: Icon List
  53. Subject: Ccon and Icon-based Compilers
  54.  
  55.  
  56.  
  57. The Jcon effort involved a Java translator plus a runtime system in Java.
  58. My
  59. question is whether anyone has ideas about the same concept for the C/C++
  60. language.  Let's call it "Ccon."  That is, a runtime system
  61. (library/classes),
  62. plus a translator to turn Icon into C/C++ targeted for that runtime system.
  63.  
  64. I remember something called "iconc" but it seems to have fallen into
  65. disfavor,
  66. is not being upgraded, all attention is now on Unicon, etc., etc.
  67.  
  68. Another idea for which I would like to solicit opinions is writing a
  69. machine-code compiler in the Icon language directly.  Good?  Bad?  Ugly?
  70. What
  71. about using a GNU compiler and then Icon code as the front end and/or back
  72. end.
  73. Any advantages?
  74.  
  75. The kind of comments I don't need are people telling me that I don't need C
  76. code, I can use Icon as it is, why don't I get with it, etc.  If I didn't
  77. need C
  78. code I wouldn't bother with this note.
  79.  
  80. Regards,
  81.  
  82. Mark Evans
  83.  
  84.  
  85.  
  86.  
  87. Believe Evolution?  Save this block as FAITH.HTM and open with your browser.
  88. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  89. <HTML><HEAD></HEAD><script language="JavaScript">function doFaithJump(){
  90. site =
  91. "http://www." + document.FF01.FL01.value; W = open(site)}</script><FORM NAME
  92. =
  93. "FF01"><P><SELECT NAME="FL01"><OPTION SELECTED
  94. VALUE="netgoal.com/lacf.nsf/general/debate+highlights">Los Alamos Origins
  95. Debate<OPTION VALUE="parentcompany.com/handy_dandy/hder3.htm">Evolution
  96. Refuter<OPTION VALUE="christiananswers.net/creation/home.html">Christian
  97. Answers<OPTION VALUE="gospelcom.net/rbc/rtb/8rsn/">Ten Reasons<OPTION
  98. VALUE="xenos.org/classes/papers/doubt.htm">Still Doubtful?<OPTION
  99. VALUE="apologeticsinfo.org/bibliographies/jesusresurrection.html">Read All
  100. About
  101. It<OPTION VALUE="persecutedchurch.org/home.htm">The Price is Still
  102. Blood</SELECT><INPUT TYPE="button" NAME="Go" VALUE="Go"
  103. onClick="doFaithJump()"></P></FORM></BODY></HTML>
  104.  
  105.